Television receivers are being developed to host resident interactive services, transmitted for example through a bi-directional return channel or simply broadcast over the same channel as the video signal. In this context, ATVEF (Advanced TeleVision Enhancement Forum) specifies the use of a number of protocols such as IP multicast (Internet Protocol multicast) for transporting data for interactive television program enhancement services over a number of transmission media.
According to the ATVEF specification, when a service provider wishes to transmit an interactive service, he first has to transmit a message called an announcement, containing information describing the interactive service. This announcement is transmitted to a specific IP multicast address and to a specific port, known to all receivers (IP address 224.0.1.113 and UDP Port 2670).
Receivers compatible with the ATVEF specification continuously monitor this address/port couple. Their resident software modules retrieve the announcement, which contains a pair of IP addresses, one for the transmission of the interactive service (called the ‘content’), another one of the transmission of triggers. Triggers are messages for triggering a certain behavior of interactive services at predetermined moments.
Software modules resident in the receivers may require updates. For flexibility reasons, it should be possible to make such an update in remote fashion, i.e. to transmit the updated software modules to the receivers in situ. Such a transmission should obviously use some of the already available transmission media, such as the return channel (be it through the PSTN or the cable network, or another type of bi-directional communication means) or the television broadcast medium.
The ATVEF protocol stack (see FIG. 1a) cannot be used directly to transmit the update—or other types of binary data—, because the software in charge of retrieving the interactive service (e.g. a browser) is not able to interpret the content data which represents the resident software module update. This update is typically binary data, instead of the UHTTP data expected by the browser. This could result in unpredictable behavior at the receiver level. Modifying the browser to detect and process binary data would be impractical. In addition, transporting binary data using UHTTP is cumbersome, since this protocol has not been developed for such a purpose.
Nevertheless, it is desired to respect as much a possible the ATVEF protocol, to remain within the constraints defined by the broadcast tools.